Several leading technology organizations are investing in building technologies that sell “software-as-a-service”. Such services provide access to shared storage (e.g., database systems) and/or computing resources to clients or subscribers. Within multi-tier e-commerce systems, combinations of different types of resources may be allocated to subscribers and/or their applications, such as whole physical or virtual machines, CPUs, memory, network bandwidth, or I/O capacity.
One of the many benefits of using the software-as-a-service approach is that providing the desired levels of availability, data durability and scalability becomes the responsibility of the service operator. Clients of the services may simply decide what levels of availability, durability and performance they wish to pay for, and leave the implementation details to the services. The service operators may consequently establish numerous data centers, often geographically distributed across different cities, states, or even countries, and populate the data centers with computing, networking, and storage infrastructure based on expectations of client usage levels for the various services. The specific resources used for a given client may be selected from several different data centers, for example, to achieve desired levels of fault tolerance and data durability. In the case of a database service, for instance, multiple replicas or instances of a given database instance may be implemented at different locations, with one of the replicas designated as the “primary” replica responsible for handling work requests at any given point in time, while the other replicas are designated as “non-primary” replicas that can each take over the primary role in the event of a failure at, or a loss of connectivity to, the primary.
In at least some scenarios in which highly available services are implemented in such a replicated manner and are configured to be accessed from a variety of network locations (such as various locations from the public Internet), a network address discovery service (such as a service based on the Domain Name System or DNS technology) may be used by clients of the service to direct work requests to the appropriate replica. When state changes occur at the service, e.g., when a primary replica fails or becomes inaccessible and a new primary is selected, the address discovery service's database may have to be updated regarding the state change. Unfortunately, in many cases some of the mechanisms available to update the address discovery service databases may themselves be slow and/or lack the desired levels of availability or reliability.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.